One difficulty I have is that it's difficult to provide some default values, because we provide multiple segmentation options, and the best choice may depend on the input technology (for example, for Visium HD we recommend using stardist, while we recommend proseg for Xenium data).

Do you have any opinion or suggestion about it?

One way I would suggest is to include config files under the conf folder and dynamically include them based on a parameter.

includeConfig {
    if (params.method == "method1") {
        "conf/method1.config"
    } else if (params.method == "method2") {
        "conf/method2.config"
    } else {
        "/dev/null"
    }
}.call()

This is similar to using config profiles

profiles {
    profile1 {
        includeConfig 'conf/method1.config'
    }
}

The only difference is that profiles can be combined and can overwrite settings of another depending on order.

Hello @mashehu,
I discussed this here on the nf-core slack

How do you think we should proceed?

@mahesh-panchal also proposed an alternative (see comment above), what do you think of this? It's very similar to the current behavior with -params-file, but uses profiles instead
One interesting aspect of -params-file is that I can use the same file for both snakemake and nextflow, which is less confusing for users and easier to maintain (also, it's an official nextflow arg, so it looks good to me).

From what I've seen, this looks like a perfect situation for profiles as that's exactly what they are meant to be used for. I'm also not sure dynamic configuration includes will still be allowed in later versions of Nextflow so profiles seem to be the most reliable way to fix this issue I think

Thanks @nvnieuwk for your comment!

So, you prefer profiles over -params-file, despite the compatibility with Snakemake (and therefore easier maintenance)?
Both works for me

NB: it won't solve the schema display on the nf-core website though, since we'll still have nested params

Yes, these nested parameters need to be flattened i am afraid. Or converted to maps.

I'm also not sure dynamic configuration includes will still be allowed in later versions of Nextflow

@nvnieuwk Is this feeling or based on a conversation somewhere? Removing dynamic configuration would complicate a lot of things, including the use of institutional configs.

Yes, these nested parameters need to be flattened i am afraid. Or converted to maps.

These parameters are already maps, as far as I understand, no? Again, I'm new to Groovy, so maybe I didn't catch something, but it seems to work well. E.g., I can overwrite a specific nested param via the command line like --paramA.paramB 3 and it will do exactly what we want.

Is that enough to use maps, @mashehu? Flattening the nested params would result in a lot of unnecessary complexity and maintenance challenges (I can provide more details why, if you want).

@nvnieuwk Is this feeling or based on a conversation somewhere? Removing dynamic configuration would complicate a lot of things, including the use of institutional configs.

This is a feeling, I'm just a bit wary with these "unsupported" ways of using configuration as these might stop working accidently. Might be something worth discussing with Ben though

So, you prefer profiles over -params-file, despite the compatibility with Snakemake (and therefore easier maintenance)?
Both works for me

Preferably yes, this way the default configurations are shipped with the pipeline, while params files usually are not shipped with the pipeline. You can still write a small script to convert your snakemake config file to a nextflow config file. That shouldn't be too difficult to do since the only things changed are the parameters.

Preferably yes, this way the default configurations are shipped with the pipeline, while params files usually are not shipped with the pipeline. You can still write a small script to convert your snakemake config file to a nextflow config file. That shouldn't be too difficult to do since the only things changed are the parameters.

Yes, it's pretty easy to do, indeed. It just means that when adding a new feature, I'll always need to ensure that both config files (Snakemake and Nextflow) are updated in the same way. Not very complicated though, I agree.
If this is the preferred solution, then I'll go with it!

Great, I'd be happy to review this change if you want :)

Hi @nvnieuwk, I made a small script to generate all the profiles, you can see the result in this commit

If it looks good to you, I can add a description for all these profiles in usage.md (I made an example description for one profile, but I can do that with all profiles and with more details).

Looks good! It might be a good idea to also add the script to the pipeline so other people can also update this later on

Alright, I added these scripts and also added a small comment for every profile in the usage.md